fix(tools): render multiline tool params as text blocks that follow generation#189
Open
cashcon57 wants to merge 1 commit into
Open
fix(tools): render multiline tool params as text blocks that follow generation#189cashcon57 wants to merge 1 commit into
cashcon57 wants to merge 1 commit into
Conversation
cashcon57
force-pushed
the
fix/tool-input-preview
branch
from
July 17, 2026 18:38
7c89caa to
e531af2
Compare
cashcon57
marked this pull request as ready for review
July 19, 2026 17:57
cashcon57
force-pushed
the
fix/tool-input-preview
branch
from
July 19, 2026 18:40
e531af2 to
bb7f821
Compare
Contributor
Author
|
Made an edit. Added the project's conventional smooth-scroll and per-character generation preview to this change. My apologies for missing that initially. Now it is in line with project conventions. Also optimized perf-wise so that it doesn't re-process the syntax highlighting of the entire doc per-character. New After:Screen.Recording.2026-07-19.at.1.42.18.PM.mov |
File-write previews rendered the whole tool input as one JSON.stringify line, so a file's newlines became literal \n escapes inside a single endless line that had to be scrolled sideways to read. Multiline (or very long) string parameters are now pulled out of the JSON preview and rendered as their own labelled block with real newlines; the remaining parameters stay as compact JSON. Inputs without such a parameter render exactly as before. Four things were needed to make that block behave while streaming: - Language detection falls back to sniffing the content when the call carries no path-like parameter to infer from. A write whose only argument is the file content is common, and without this it defaulted to markdown and rendered essentially uncoloured. - Highlighting is self-pacing: a new pass starts only once the previous one finishes, always against the newest value. Rendering every queued result replays a growing backlog of stale frames, while dropping any result that is no longer newest starves them all; skipping the intermediate values keeps the view current at whatever rate the machine sustains. - Only a bounded window of trailing lines is highlighted while streaming. Re-tokenising the whole document makes each pass more expensive as the file grows, so the preview slows down the longer a write runs; the view is pinned to the tail meanwhile, so only the tail can be seen. The complete document is rendered once the write finishes. - The block follows the tail using the same use-stick-to-bottom behaviour as the conversation, which scrolls an inner element sized to 100% height and so needs a definite height on its wrapper — with only a max-height nothing overflows and the preview clips instead of following. Long lines wrap rather than scrolling sideways, since a horizontal scrollbar appearing mid-stream shifts the scroll maths and cancels following. Adds unit tests for the split and for language detection.
cashcon57
force-pushed
the
fix/tool-input-preview
branch
from
July 19, 2026 18:46
bb7f821 to
61194e7
Compare
Collaborator
|
Thank you for your work on this! We’ve integrated your changes while preserving your commits and authorship, and they are planned to ship in the next Atomic Chat release. We really appreciate your contribution! |
Contributor
Author
|
@Vect0rM thanks, Mike! I've been so happy to get to contribute to Atomic Chat. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Describe Your Changes
Tool-call parameter previews were unusable for file writes (and any tool with a
chunky text parameter): the input renders as one
JSON.stringifyline, so thecontentstring's newlines become literal\nescapes inside a single endlessline, and the scroll box stays pinned to the top while the input streams, so
you can't watch what's being generated.
Two changes in
ToolInput:containing newlines (or ≥400 chars) are pulled out of the JSON preview and
each rendered as its own labeled block with real newlines; the highlight
language is guessed from a path-like sibling parameter (
path,file_path, …). Remaining parameters stay as compact JSON. Inputs withoutsuch parameters render exactly as before, so small tool calls are
unaffected.
runs throughout the write, self-paced so a new pass starts only once the
previous one finishes against the newest value (rendering every queued
result replays a backlog of stale frames; dropping any result that is no
longer newest starves them all). Only a bounded window of trailing lines is
highlighted while streaming, so the pass stays a fixed cost instead of
growing with the file, with the complete document rendered once the write
finishes. Following the tail uses the project's existing
use-stick-to-bottombehaviour, so it eases rather than snapping andreleases when the reader scrolls away.
The split/guess logic lives in
lib/toolParamPreview.tswith unit tests(multiline extraction, long-string extraction, non-object passthrough,
language guessing). Verified in a local dev build against the filesystem MCP's
write_file:contentrenders as real multi-line text and the block followsthe tail as it streams, collapsing to a highlighted code block when done.
Fixes Issues
Before/After
Before:
Screen.Recording.2026-07-19.at.12.40.32.PM.mov
After:
Screen.Recording.2026-07-19.at.12.53.26.PM.mov
Self Checklist